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(57) This invention relates to a method of loading 
Java ClassFlles on to a Java Virtual Machine. On a reg- 
ular JVM the ClassFile are loaded as and when 
required. In this specification there is described a 
method of implementing an object oriented prop-am 
language such as Java on a computer. The method 
comprises identifying a class, one of the basic building 
blocks of the language, which is not within the pro-am 
domain, that is not loaded into the Java a Virtual 
Machine. Next it introduces to the program domain only 
the minimum components of the class which are neces- 
sary for commencing processing of the class. The class 
may comprise several blocks of data representing the 
methods of the class, since the class may only have 
been identified because one of the methods within the 
class was referenced then only the block of data repre- 
senting this method is loaded into the Java Virtual 
Machine along with the other essential components of 
the class. Other blocks of data representing methods 
can be loaded as and when required by the program- 
ming domain. Redundant method corrponents may be 
removed from the program domain to save memory. 
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Description 



[0001] This invention relates to a dass loading 
mode! for an object orientated programming language. 

BACKGROUND 

[0002] The size and price of memory chips has 
decreased steadily since the advent of computers and 
as a consequence the storage capacity on a machine 
has increased considerably over time. Ten years ago 
64k bytes of RAM was the norm, now it is 64M bytes 
and in the next ten years it will possibly be 64Q bytes. 
This Increase in RAM memory storage on a computer 
has been followed if not lead by an increase on the 
demands on storage by larger memory intensive soft- 
ware applications. One solution introduced by some 
operating systems to reduce the RAM memory required 
is to us dynamic linking of class libraries, that is to only 
load Iforaries of classes when they are needed by an 
application. This allows the available RAM to be used 
more efficiently. One problem with loading whole sets of 
classes is that more classes are loaded than are actu- 
ally used and time is wasted loading the unused 

classes. . 
[0003] Dynamic loading of individual classes is part 
of a Java enabled environment whereby a small applica- 
tion or applet is dynamically sent from server to client on 
request The applet comprises a number of Java 
classes needed for the execution of the applet and a set 
of classes may be loaded in a container called a Jar or 
an individual class may be loaded. In this way the Java 
environment is saves memory by only loading the 
classes ft needs to run the application or applet. Time is 
also saved as only the classes that are needed are 
loaded. However, speed of operation of the Java envi- 
ronment is critical and a major drawback of using the 
Java language. 

SUMMARY OF THE INVENTION 

[0004] According to one aspect of the invention 
there is provided a method of processing a class file on 
a conputer system comprising: identifying independent 
parts within the class; creating separate components for 
each separable part of the class; and storing the com- 
ponents so that each component of the class is individ- 
ually identif iable and accessible. 
[0005] In this way the granularity of loading is 
increased within the classes with only the components 
needed within the class being loaded and used. This 
leads to an increased speed of operation and a reduc- 
tion in the memory needed. . 
[0006] The separable parts of the class identified 
are the class meta data part and the methods part 
Although the ClassFfle is a serialised sequence of byte 
code, the meta data part and method byte code parts 
are contiguous and not combined allowing separation 



and extraction from the ClassFile. 
[0007] In th case where a method requires other 
methods in the class for its operation the meta data 
component contains information indicating which meth- 
5 ods are dependent and should loaded together. This 
allows the method loader to be more efficient in the 
loading of the individual methods whereas, if each 
method was loaded only when referenced, the speed of 
operation of the system would be reduced. 
10 [0008] According to another aspect of the invention 
there is provided a method implementing an object ori- 
ented program language on a computer comprising: 
identifying a class which is not within the program 
domain; and introducing to the program domain only the 
is minimum corrponents of the class which are necessary 
for commencing processing of the dass. The program 
domain is the environment in which the program runs 
and in this embodiment it is a Java Virtual Machine 
"JVM". The object oriented language is the Java pro- 
20 gramming language which is loaded into the JVM as 
classes and is processed by interpreting the bytes 



[0009] Advantageously the method further com- 
prises identifying a separable meta data component 
25 and separable method components of the class and 
introducing the meta data component and only the min- 
imum number of method components to the program 
domain. The meta data component may itself be sepa- 
rated into further components to further increase the 
30 level of granularity. 

[0010] Furthermore the method further comprising 
setting a field in the program domain to indicate that 
method byte code for that method has not been down- 
loaded to the client. This field points at a mechanism for 
35 loading the component of method byte code. 

[0011] Classes are packaged into ClassFiles for 
distribution and contain components of execution code 
called methods that may or may not be used during the 
execution of a program. Due to the over supply of meth- 
40 ods such classes are bulky in terms of byte code; this is 
a major factor in the transfer time from the server to the 
client Due to the number of applet transfers that take 
place over the Internet at present and the expanding 
number of Java applications envisaged in the future it 
45 would be desirable to reduce the transfer time for Java 
applications and applets 

[001 2] Use of skeletal Java classes is known in the 
design of remote applications. However this skeletal 
class contains only basic metadata including visual 

50 information and other data needed for designing an 
applet. No method data is included in this skeletal dass 
as the skeletal class is not intended to be executed. 
[0013] The class metadata comprises a class 
description component a method table and a constant 

55 pool. 

[0014] Despite Java's compact representation, the 
classes distributed are often numerous and large. Much 
of the bulk of a class is made up of the methods them- 
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selves. Often, many of the methods downloaded are 
never used on any given occasion. This invention pro- 
poses the distribution of class data at a method level of 
granularity. This results in the following scenari : 

5 

1) A client program requires the use of a remote 
class 

2) A skeleton definition of the class is sent to the cli- 
ent State metadata and constant pool information 10 
is downloaded at this point together with any 
method identified as always needing to be down- 
loaded. 



3) When a method is actually referenced, lazy veri- is 
f ication also triggers the downloading of that frag- 
ment of the class file. Only those methods actually 
referenced are transferred. 

[0015] As a result of this invention the following is so 
achieved: reduced network stress as a result of the 
reduced data flows; reduced base memory require- 
ments of the Java application improved client perform- 
ance as a result of the above; and improved client 
performance as a result of a more incremental down- 25 
load. 

[0016] The Java class loader is modified so that 
only the minimum amount of class metadata is down- 
loaded initially. The existing method reference opcode 
are modified so that the method code is downloaded at 30 
the time of first reference. Once the method is down- 
loaded, the opcode is replaced with its 'quick* counter- 
part If the method was previously downloaded by 
another reference, subsequent references are resolved 
using the existing mechanisms. 35 
[0017] The application proposes that the classes 
should be loaded without their methods. The methods 
represent most of the bulk of the class and are often 
never referenced. 

[0018] The lazy verification is extended to cause 40 
the downloading of individual methods as they are refer- 
enced. 

[0019] Components of the class which are no 
longer used by the application may be discarded to free 
up the memory space, this is similar to garbage codec- 45 
ti n of unused classes but on a finer granular scale. One 
extreme way to discard unused components would be 
to discard all the methods not active on the Java stack, 
if the individual components were needed later they 
could be reloaded with ease. so 

DESCRIPTION OF THE FIGURES 



Figure 2 is a representation of the relationship 
between the byte code of the class sent over the 
network, the class as it exists in the client after load- 
ing from the server and class as it exists on the 
server; 

Figure 3 shows steps taken in loading a class file or 
a skeletal class file; 

Figure 4 shews the process of loading a method for 
interpretation used by the present invention. 



[0020] 



Figure 1 is a representation of the transformation of 
a Java application after Java compilation and after 
processing by a method of the embodiment; 
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[0021] Referring to Figure 1 there is represented a 
Java source code applet xjava 10 , such source code is 
typically written using an editor and then compiled using 
a Java compiler or Javac to the object code or byte 
code. The byte code is represented as x.class 12 and 
y.class 14 in Figure 1. The classes are self contained 
pieces of program code comprising metadata and meth- 
ods for each class. Due to the nature of the class struc- 
ture, a class may be copied and transferred only as a 
whole. A post compilation process is applied to th 
classes in order to break down the self contained struc- 
ture of the classes and convert a seK contained class 
into individually accessible components of a class. 
These components may copied and distributed individ- 
ually and not as a collection. In this embodiment the 
class is broken down into a metadata component 16 
(x.meta) and individual method components 
xm1 .method 18A , x.m2. method 18B and x.mn.method 
18C etc. The original ClassFile is also stored so that it 
may be loaded if needed instead of the components. 
[0022] Each individual accessible component is a 
part of the class that is separable. In this embodiment 
the example for separable components are the meta- 
data within the class and the individual methods. How- 
ever it is feasble that other separable parts of the class 
may be made individually accessible, for instance parts 
of the constant pool may be formed into individually 
accessible parts. Other ways of breaking down a class 
fDe are possible, for instance one could group some 
methods together if they were dependent on one 
another. This could be indicated in the class metadata 
where the 'compulsory methods' for downloading were 
referenced. The classtoader would check for 'compul- 
sory methods' in the metadata when the class was first 
loaded and load those methods referenced. 
[0023] As part of the normal ClassLoading opera- 
tion, a class is sent over a network in its entirety as a lin- 
ear sequence of bytes codes 20 forming a ClassFile. 
During class loading the client receives the linear 
sequence of bytes codes 20 and reconstructs the class 
structure. This structure is similar to what is seen in Fig- 
ure 2 showing the class metadata and methods. From 
the class metadata 1 6 is constructed a class description 
table 22, a constant pool 24 and a method table 26 . The 
class methods are represented by the byte code for 
method 1 and method 2. The difference between typical 
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class loading and the class loading of the embodiment 
is that the byte code for all the methods is not necessar- 
ily loaded. In Figure 2 the byte code of method 2 is not 
loaded and the method 2 pointer in the method table 
points to a method invoker 28. 
[0024] The class description component comprises 
links for the constant pool and the method table. The 
constant pool defines constants used by the class. The 
method table comprises the names of the methods 
used by the class and links to the methods or method 
invokers for that method. A method invoker is a routine 
for dealing with a type of method, for instance a byte 
code method would have a method invoker for starting 
the JVM interpreting the byte code; method. A compiled 
method would have a JIT method invoker to execute the 
compiled code. A method that was not initially loaded as 
part of the minimum class requirement would have a 
method table pointer to a method loading invoker rou- 
tine. When the method is needed, a lookup on the 
method table would lead to a method loader call to load 
the method. The present embodiment uses a load 
method invoker (modified class loader) to retrieve the 
method component that has not been loaded onto the 
client. The modified class loader can then search for the 
location of the method component in a method compo- 
nent directory or, as indicated in figure 2, find the loca- 
tion in the method invoker itself. 
[0025] When an applet is downloaded from a server 
t the client by the modified class loader the process is 
as follows (see Figure 3). Initially a user or another 
application will instigate the downloading of an applet 
the applet will comprise a number of classes and the 
modified class loader will be asked to load x.dass (step 
1). Instead of downloading the xclass in its entirety, the 
modified class loader assumes that the class has been 
componentised by the post compilation process and 
attempts to download the x.meta component of the 
class (step 102) . If this is not successful the modified 
class loader then loads the xxlass in its entirety just as 
a typical class loader (step 1 04). If this is successful the 
x.meta component 16 is loaded into the client and the 
description component 22, constant pool 24, method 
tab! 26 and invoker components 28 set up (step 105) 
as in Figure 2. The modified class loader then sets the 
non-loaded method pointers in the method table to point 
at a method loader invoker 28 so that a non-loaded 
method is loaded immediately it is referenced. This is 
the quick method load and is normally instigated by an 
instruction which references a class method. Referring 
now to Figure 4, a 'non-quick* method load operates as 
follows. 

[0026] A Java applet is being interpreted by the 
JVM and an instruction references a class method (step 
201). This method is looked up in the method table of 
the class (step 202), the class ffle or at least the class 
metadata having already been downloaded from the 
server. The method table identifies the method loader 
routine is to be used (step 203). The method loader rou- 



tine looks up the location of the method component from 
the class description (step 204) and downloads the 
component from the server to the client (step 205). Next 
the method component goes through the normal verrfi- 

5 cation process as it would have done if the class ffle had 
been loaded in its entirety (step 206). The method 
invoker can now be set to point at the location of the 
byte code method in the client rather than the method 
loader routine (step 207). The method byte code is writ- 

70 ten to the location pointed at by the invoker (step 208). 
Next time the method is referenced the JVM will know 
that a quick method load can be made. The method 
load next re-executes the invoke method routine and the 
JVM interprets the method as per normal (step 209). 

is [0027] In summary there is described a method 
relating to the loading of Java ClassFfles on to a Java 
Virtual Machine. On a regular JVM ClassFiles are 
loaded as and when required. In this specification there 
is described a method of implementing an object ori- 

20 ented program language such as Java on a computer. 
The method comprises identifying a dass, one of the 
basic building blocks of the language, which is not within 
the program domain, that is not loaded into the Java Vir- 
tual Machine. Next it introduces to the program domain 

25 only the minimum components of the class which are 
necessary for commencing processing of the class. The 
class may comprise several blocks of data representing 
the methods of the class, since the class may only have 
been identified because one of the methods within the 

30 class was referenced then only the block of data repre- 
senting this method is loaded into the Java Virtual 
Machine along with the other essential components of 
the class. Other blocks of data representing methods 
can be loaded as and when required by the program- 

35 ming domain. Redundant method components may be 
removed from the program domain to save memory. 

Claims 

40 1 . A method of processing a class file on a compu- 
ter system comprising: 

identifying independent parts within the class; 
creating separate components for each sepa- 
45 rable part of the class; and 

storing the components so that each compo- 
nent of the class is individually identifiable and 
accessible. 

so 2. A method as claimed in claim 1 wherein the inde- 
pendent parts of the class identified are the class 
metadata and the methods. 

3. A method as claimed in claim 1 or 2 wherein the 
55 metadata component contains information indicat- 
ing which methods are dependent and should 
loaded together. 
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4. A method as claimed in claim 1, 2 or 3 wherein 
the processing is performed on Java byte code 
ClassFile. 

5. A method implementing an object oriented pro- s 
gram language on a computer comprising: 

identifying a class which is not within the pro- 
gram domain; and 

introducing to the program domain only the 10 
minimum components of the class which are 
necessary for commencing processing of the 
class. 

6. A method as claimed in claim 5 further compris- is 
ing identifying a separable meta data component 
and separable method components of the class 
and introducing the meta data component and only 
the minimum number of method components to the 
program domain. 20 

7. A method as claimed in claim 5 or 6 further com- 
prising setting a field in the program domain to indi- 
cate that method byte code for that method has not 
been downloaded to the client. 25 

8. A method as claimed in claim 7 wherein the field 
points at a mechanism for loading the component of 
method byte code. 

30 

means for creating separate components for 
each separable part of the class; and 

means for storing the components so that each 
component of the class is individually kJentrfia- 35 
We and assessible. 

10. A computer program product, stored on a com- 
puter readable storage medium, for executing com- 
puter program instructions to carry out the step, of 40 
a method as claimed in claim 1 . 



45 



SO 



55 



_0996Q59A2_I_: 



5 



EP0996 059A2 



Javac 



Post Compile Process 




xmetn 
16 



xinl jncth 
IRA 



xrol.meth 
I8B 

xm2.mcth 
IRC 



Source Code 



Object Code 



Component Object 
Code 



Figure 1 



6 



EP 0 996 059 A2 



Server 



Class x.meta 
16 



x.ml.meth (byte code) 
I8A 



x.m2.meth (byte code) 
18B 



Client 



Class. x description 



22 




Sequence of bytes codes for class.x 
20 



24 



1 Method Table 




Byte Code for method 
I 










26 


22 



Method Invoker 




28 





Figure 2 



JOOCID: <EP 09960SSA2_I_> 



7 



EP 0 996 059 A2 



ClassLoader is asked to toad 
class, x 

101 



I 



ClassLoader attempts to load 
x.meta 
102 



T 




Success? 
103 



YES 



load class.x 
104 



Load x.meta 
105 



lnvoker set to "Method Loader* 
routine 
106 



Figure 3 



8 



EP0 996 059 A2 



Instruction references class method 
201 

♦ 

Lookup method in method table 
202 

» 

Method laoder routine referenced by method table 

203 

♦ 

Use class info to locate method component 
204 

♦ 

Load method component (x. ml. met hod) 
205 

» 

Perform method related verification 
206 

* 

Replace method invoker 
207 

* 

Replace byte code with quick version 
208 

* : 

Re-execute invoke 
209 



Figure 4 

9 



ec. 



PAGE BLANK (uspioj 



INTI 



VTIONAL SEARCH REPORT 



1^ 

PCT/US 02/08735 



national Application No 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 G06F9/445 



According to International Patent Classification (IPC) or to both national classification and IPC 



B. RELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 7 606F 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practical, search terms used) 

EPO-Internal , WPI Data, PAJ, INSPEC 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ° Citation of document with Indication, where appropriate, of the relevant passages 



Relevant to claim No. 



CHANG D-W ET AL: "EJVM: AN ECONOMIC JAVA 
RUN-TIME ENVIRONMENT FOR EMBEDDED DEVICES" 
SOFTWARE PRACTICE & EXPERIENCE, JOHN WILEY 
& SONS LTD. CHICHESTER, GB, 
vol. 31, no. 2, February 2001 (2001-02), 
pages 129-146, XP000987539 
ISSN: 0038-0644 
page 130, line 14-20,28-34 

line 5,6,12-18,39,40 
line 34 -page 133, line 11 
line 7-12 
line 6,7 
abstract; figures 1,2 



-/-- 



I- 7, 

II- 16, 
19-21 



page 131, 
page 131, 
page 135, 
page 136, 



8-10,17, 
18 



OH 



Further documents are listed (n the continuation of box C. 



Patent family members are listed in annex. 



° Special categories of cited documents : 

*A' document defining the general state of the art which is not 
considered to be of particular relevance 

E° earlier document but published on or after the international 
filing date 

L a document which may throw doubts on priority claim(s) or 
which Is cited to establish the publication date of another 
citation or other special reason (as specified) 

O* document referring to an oral disclosure, use, exhibition or 
other means 

P* document published prior to the International filing date but 
later than the priority date claimed 



"T* later document published after the International filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
Invention 

•X' document of particular relevance; the claimed Invention 
cannot be considered novel or cannot be considered to 
Involve an Inventive step when the document is taken alone 

"V document of particular relevance; the claimed Invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
In the art 

*&* document member of the same patent family 



Date of the actual completion of the international search 



25 September 2003 



Date of mailing of the International search report 

17/10/2003 



Name and mailing address of the ISA 

European Patent Office, P.B. 5618 Patent taan 2 
NL - 2280 HV Rijswijk 
TeL (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax (+31-70) 340-3016 



Authorized officer 



de Junca, I 



Form PCT/1SA/210 (second sheet) (July 1992) 



page 1 of 2 



THIS PAGE BLANK iuspto) 



INT^ VTIONAL SEARCH REPORT 



IC 



national Applleatlon No 

PCT/US 02/08735 



C(Contlnuatlon) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document, wtth indication, where appropriate, of the relevant passages 



Relevant to claim No. 



GOSLING J ET AL: "THE JAVATM LANGUAGE 
SPECIFICATION" 

JAVA LANGUAGE SPECIFICATION, XX, XX, 

1 August 1996 (1996-08-01), pages 
215-236, XP002042923 
page 218, paragraph 12.2 
page 216, line 12-14 
page 219, paragraphs 12.2,12.2.1 

ZHENYU QIAN: "A formal specification of 
Java Virtual Machine Instructions" 
TECHNICAL REPORT, UNIVERSITAT BREMEN, 
•Online! November 1997 (1997-11), 
XP002255760 

Retrieved from the Internet: 

<URL : http ://c1 teseer . n j . nec . com/cache/pape 

rs/cs/874/http : zSzzSzwww. d s . upenn . eduzSzf 

5cp1ercezSzcourseszSz629zSzpaperszSzQ1an-J 

VMspec . pdf /q1 an97f ormal . pdf > 

'retrieved on 2003-09-25! 

page 3-5, paragraph 3 

EP 0 996 059 A (IBM) 

26 April 2000 (2000-04-26) 

abstract; claim 1; figure 1 

column 6, line 21-36 

column 1, line 44 -column 2, line 7 

column 3, line 27-31 

column 4, line 18-47 

US 6 072 953 A (KING RICHARD ADAM ET AL) 
6 June 2000 (2000-06-06) 
column 3, line 49 -column 4, line 12 
column 4, line 58 -column 5, line 11 
column 6, line 28-40; figure 4 



11,12,15 



8-10,17, 
18 



1-21 



1-21 



Form PCT/iSA/210 (continuation of second sheet) (July 1992) 



page 2 of 2 



PAGE BLANK (uspto) 



